home *** CD-ROM | disk | FTP | other *** search
/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d20 / tick207.arc / BETATICK.DOC next >
Text File  |  1991-02-08  |  13KB  |  291 lines
  1.  
  2.  
  3.  
  4.                                    Betatic.doc
  5.  
  6.                 Tick 2.01 -
  7.  
  8.                 *  Fixed the INTL line in MSG attaches so that it terminates
  9.            with a CR/LF rather than with just a LF.
  10.  
  11.                 *  Fixed a bad error message which occurred when you had  an
  12.            invalid zone.
  13.  
  14.  
  15.                 Tick 2.02 -
  16.  
  17.                 *    Fixed  a  couple  of  spots  where an error would be be
  18.            properly handled, but not logged.
  19.  
  20.                 * TICK now has PASSTHRU capability!    To  make  an  area  a
  21.            passthru area,  place a "LOCAL PASSTHRU" entry in its AREA block,
  22.            as you would other "LOCAL" keywords.   That will  activate  addi-
  23.            tional  processing.    TICK will make its attaches as usual,  but
  24.            will *not* update the FILES.BBS.   At each run  thereafter,  TICK
  25.            will  test all attaches (either MSG or FLO's,  for FIDO or native
  26.            mode respectively),  and will kill the file when there are no ac-
  27.            tive  attaches.    If  the passthrough file is also a pre-release
  28.            file, the passthrough process will be postponed until the file is
  29.            released.  Be aware that if you define a secondary area, and that
  30.            secondary area is passthru,  the file will be  tossed  there  and
  31.            treated as a passthru file (ie - deleted).   Likewise,  if a non-
  32.            passthru area is secondary to an area that *is* passthru, the in-
  33.            bounds will be tossed to the non-passthru  area  and  treated  as
  34.            non-passthru.   (These actions will be infulenced by stopdup,  as
  35.            previously).  A note of caution ...  This code is new,  and there
  36.            could be some risk of inadvertant loss of files if there are bugs
  37.            in it.   I have run preliminary tests,  which appear to have gone
  38.            OK.
  39.  
  40.                 Tick 2.03 -
  41.  
  42.                 *  I forgot to mention that the maximun number of nodes  per
  43.            area has been increased to 100, as of 2.02.
  44.  
  45.                 *   As per popular request,  TICK now provides for "Terminal
  46.            Nodes".  If a node has a "T" flag, it will receive the FILE,  but
  47.            not the TIC.
  48.  
  49.                 *   Fido mode MSG attaches will once again try to make *ONE*
  50.            MSG for both file and TIC,  unless the file being processed is  a
  51.            pre-release file.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                            1
  59.  
  60.  
  61.  
  62.                                    Betatic.doc
  63.  
  64.                 Tick 2.04 -
  65.  
  66.                 *    Tick  users may now choose between the "#" flag and the
  67.            "^" flag in FLO files,  to select the method of killing  the  TIC
  68.            files  after they are sent.   The default is to set the "#" flag,
  69.            which instructs the mailer to truncate the  file  after  sending.
  70.            TICK  will  delete  it  on  the following run.   If you place the
  71.            keyword "MailerKills" in the CFG file,  TICK  will  use  the  "^"
  72.            flag, and assumes that the mailer will kill the TIC file after it
  73.            is sent.   NOTE:  When you first make this conversion, any exist-
  74.            ing attaches of TICs will still be truncated rather than deleted.
  75.            You will need to either run a program that will kill the  remain-
  76.            ing  0-length  files  in  the HOLD directory (such as Kill0.LZH),
  77.            delete  them  manually,  or  do  a  run  of  TICK  *without*  the
  78.            MailerKills flag to get rid of those old ones.
  79.  
  80.                 *    Tick will now try to *deactivate* a poorly defined AREA
  81.            instead of aborting the program.   If a file  for  a  deactivated
  82.            area  comes  in  ,  TICK  will act as if the area does not exist.
  83.            Please test this with such things  as  non-existant  directories,
  84.            etc.
  85.  
  86.                 Tick 2.06 -
  87.  
  88.                 *  There  is a new configuration keyword for HATCH.   If you
  89.            add the keyword "RAID" to your TIC.CFG, HATCH will generate a new
  90.            file in the HOLD directory.   The file will  have  the  extention
  91.            "RAD",  and should enable a future version of RAID (and any other
  92.            file anouncement program that cares to use it) to announce  files
  93.            that are locally hatched.
  94.  
  95.                 *  TICK  and  HATCH  are  now being compiled with MSC 6.00A.
  96.            Watch for any strange behavior.
  97.  
  98.                 *  TICK now supports a REPLACE function.   If an inbound TIC
  99.            has a "Replaces abc.xyz" line in it, and if you configure TICK to
  100.            allow  it,  the  old file (if it exists in the destination direc-
  101.            tory) will be either deleted or moved to  a  different  directory
  102.            before  the  new  file is moved to the destination.   To activate
  103.            this feature,  add the keyword "REPLACE" to your TIC.CFG.    That
  104.            will  cause  the replace function to be active in all areas,  and
  105.            will result in old versions being DELETED if the inbound TIC  has
  106.            that  name as the parameter of the REPLACES line.   If you follow
  107.            the "REPLACE" keyword with a vaild directory name,  the old  file
  108.            will be moved there instead.   If a file by the same name already
  109.            exists in the "old file" directory,  TICK  will  leave  the  file
  110.            alone  and  note that in the log.   The Replace function does not
  111.            accept wildcards for replacement ...  I felt  that  the  security
  112.            issues  were  too  great.    There  are  also  2 additional LOCAL
  113.            keywords ... If you have put a REPLACE line in your TIC.CFG,  but
  114.            do  NOT want to allow replacements in certaing areas,  then add a
  115.  
  116.                                                                            2
  117.  
  118.  
  119.  
  120.                                    Betatic.doc
  121.  
  122.            "LOCAL NoReplace" line in those AREA blocks (after the AREA line,
  123.            but before the node list).   If you do NOT want REPLACE to be ac-
  124.            tive in most areas,  but DO want it in certain areas, then do not
  125.            put a REPLACE line in your TIC.CFG,  and add  a  "LOCAL  REPLACE"
  126.            line to those AREA blocks.  Note that if you want a replaced file
  127.            to  be MOVED to an "old files" directory,  you must put a REPLACE
  128.            line in the CFG.   (ie  -  Local  "Replace  c:\oldfiles"  is  NOT
  129.            valid).    I  should  mention that TICK will not remove the entry
  130.            from the FILES.BBS at this time.   There are many permutations of
  131.            CFG's  with  this feature,  please pound on it to shake loose any
  132.            bugs that might be lurking.
  133.  
  134.                 * HATCH now accepts an optional command line switch to allow
  135.            you to designate a filename to replace with the file you are  now
  136.            hatching.   The switch is /X, and must be immediately (no spaces)
  137.            followed by the filename you are replaceing.  The filename should
  138.            NOT contain a path,  Drive letter,  or wildcard characters (*  or
  139.            ?).    There  is presently no interactive prompt for a "Replaces"
  140.            filename.  (Should there be one?)
  141.  
  142.  
  143.                 TICK 2.06b -  (HATCH only)
  144.  
  145.                 * Corrects a bug in HATCH introduced in 2.06 ...  If you en-
  146.            tered the filename from the command line,  it was being truncated
  147.            to 13 characters.   That was fine if you were using  the  default
  148.            directory  and allowing HATCH to determine the directory,  but if
  149.            you wanted to HATCH something  from  another  directory,  it  was
  150.            failing.
  151.  
  152.                 *    HATCH  now will prompt for a "replacement file" name if
  153.            you don't provide it on the command line.   To bypass the  prompt
  154.            when  running in a batch file,  you can supply the "/X" without a
  155.            filename appended ... ie - "Hatch /ffoo.txt /xold.txt" results in
  156.            the file Foo.yxy being hatched,  and  replacing  old.txt  on  the
  157.            receiving  nodes;  "Hatch  /ffoo.txt /x" will hatch the same file
  158.            and not prompt for a replacement;  and   "Hatch  /ffoo.txt"  will
  159.            hatch the file and prompt you for a replacement file name.
  160.  
  161.                 TICK 2.06c -
  162.  
  163.                 *  Tick  was  in some cases generating duplicate attaches to
  164.            the same node.  When I re-compiled it with MSC 5.1 instead of MSC
  165.            6.00A, the problem seems to have gone away.
  166.  
  167.                 TICK 2.06d -
  168.  
  169.                 * This version fixes a bug where each TICK that processed  a
  170.            file  containing  a  RELEASE line added another "release" line to
  171.            the TIC.
  172.  
  173.  
  174.                                                                            3
  175.  
  176.  
  177.  
  178.                                    Betatic.doc
  179.  
  180.                 *  New implementation of the NoWait option and the  /X  com-
  181.            mand line option ...  Originally, NoWait was not really foolproof
  182.            when it came to unattended operation of HATCH.   It assumed  that
  183.            the operator had made a batch file that insured that the required
  184.            items,  such as /fFile.ext and /aAreaname were provided.   If the
  185.            items provided were invalid, it would abort the hatch,  so as not
  186.            to  hang the batch.   If you failed to provide a filename or area
  187.            altogether, it would still prompt you.  This version now tries to
  188.            catch this type of error.   If there is missing required informa-
  189.            tion,  Hatch  should  now abort if the /ON flag is in the command
  190.            line, or if NoWait is in the CFG.  Also ... If you have specified
  191.            Nowait (/on),  There is never a prompt for a "replaces"  file  or
  192.            for a RELEASE date.  (You should no longer need to put the /R0 in
  193.            the  command  line).    If  you put the /Xfile.ext in the command
  194.            line,  then file.ext will be used as the REPLACE file.    If  you
  195.            omit  /X,  there will be no replace file,  and if you put "/X" in
  196.            the command line, but provide no replacement filename there,  the
  197.            "/X"  will  be  ignored.    If  you  run  in the interactive mode
  198.            (without the "/on" or NoWait),  then you will be prompted  for  a
  199.            replacement file unless you provide one on the command line.
  200.  
  201.                 TICK 2.07 -
  202.  
  203.                 *    Adds  the  LOCAL STOPDUP feature mentioned in the echo.
  204.            For those of you who might have missed it, here's how it works:
  205.  
  206.                 First,  You still need to have the main [STOPDUP  c:\dupdir]
  207.            line  in your TIC.CFG to activate STOPDUP processing in the first
  208.            place.   The presence of a LOCAL STOPDUP in an area all by itself
  209.            will NOT turn on STOPDUP in that area.
  210.  
  211.                 If  you  do  not  put a [LOCAL STOPDUP dupfile] statement in
  212.            your area, then that area's dup file will use the area's tag with
  213.            a DUP extention as the filename for its dup file, as before.   If
  214.            you *do* put in the new local line,  then the "dupfile" name that
  215.            follows the "Local Stopdup" will be the root name  for  that  dup
  216.            file.  It will be appended with a DUP extention.  For example:
  217.  
  218.                 AREA d:\file\long BRAVO
  219.                 Local Stopdup Tango
  220.                 1:266/12 password *C
  221.                 1:13/13 wordpass C
  222.  
  223.                 The  DUP  file for the above area would be called Tango.DUP,
  224.            and would reside in the Dup directory specified  in  the  regular
  225.            STOPDUP  cfg line.   Without the local line,  the file would have
  226.            been called BRAVO.DUP.
  227.  
  228.                 What this does is gives you the option  of  merging  certain
  229.            echos to use the same DUP file.   This possibility should be used
  230.            with care.  Just because *YOU* happen to carry both of the merged
  231.  
  232.                                                                            4
  233.  
  234.  
  235.  
  236.                                    Betatic.doc
  237.  
  238.            echos,  that doesn't always insure that all your downstream nodes
  239.            carry both echos.  If a DUP entry generated from echo A stops the
  240.            same file from passing in echo B, you may be preventing nodes who
  241.            carry only B from getting it at all.
  242.  
  243.  
  244.  
  245.                      Barry Geller
  246.                           609-482-8604
  247.                                1:266/12
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.                                                                            5
  291.